iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 16
1

本文同步刊登於個人技術部落格,有興趣關注更多 Kubernetes、DevOps 相關資源的讀者,請務必追蹤從零開始的軟體工程師之旅,喜歡的話幫我按讚分享、歡迎留言、或是許願想要看的文章。

如果有技術問題也可透過粉絲專頁 討論,技術方面諮詢免錢、需要動手做另計 XD。

曬貓


Preemption selection

除了 24 小時的壽命限制會終止虛擬機,資料中心的事件也會觸發主動的虛擬機回收,由 GCP 主動觸發的回收機制機率很低,會根據每>日每個區域 (zone) 的狀態而定。這裡描述資料中心啟動的臨時回收。

GCP 不會把所你手上的 preemptible 機器都收走,而是依照一定的規則,選擇一個比例撤換的機器。

先看文件敘述

  • Compute Engine 會避免從單一客戶移除太多先占虛擬機
  • 優先移除新的虛擬機,偏向保留舊的虛擬機 (但最多仍活不過 24hr)
  • 開啟後馬上被移除的先占虛擬機不計費
  • 機器尺寸較小的機器,可用性較高。例如:16 cpu 的先占虛擬機,比 128 cpu 的先占虛擬機容易取得

GCP 每天平均會移除一個專案中 5% - 15% 的虛擬機,從用戶的角度我們需要預期至少這個程度的回收。不過這個比例,GCP 也不給予任何保證。以筆者經驗,只能說絕大部分的時候,都不會擔心超過這個比例的回收,但是還是要做
好最壞的打算,如果臨時無法取得足夠的先占虛擬機,要有方法暫時補足隨選虛擬機。

GKE

使用先占虛擬機會違反 Kubernetes 的設計

對應用的影響

GCP 觸發的 Preemptible process,對應用的影響

  • involuntary disruptions,GCP 送 ACPI G2 Soft Off
  • OS 終止服務,包含執行 Kubernetes 的 container runtime
  • 容器內的應用會收到 SIGTERM,啟動 graceful shutdown
    • Kubernetes 提供的 Graceful-shutdown 可能會跑不完
    • 實務上只是中斷當前工作

https://cloud.google.com/solutions/scope-and-size-kubernetes-engine-clusters

大量節點同時回收

由於 GCP 並不保證收回的機器的數量,同時回收的機器量大,還是會衝擊到服務。例如:一次收回 15% 的算力,當然服務還是會受到衝擊。當然這樣事件的機率並不高,但我們仍是需要為此打算。這邊有幾個做法

  • 預留更多的算力
  • 使用 regional cluster,在多個 zone 上分配先占虛擬機
  • 我們自行控制,提前主動回收虛擬機

預留更多資源

這點很直觀,由於使用了更加便宜的機器,我們可以用同樣的成本,開更多的機器。

退一步說,使用打三折的先占虛擬機,然後開原本兩倍的機器數量

  • 總成本是 0.3 * 2 = 0.6 倍
  • 同時間可用資源是 2 倍

由於先占節點回收的單位是一個一個虛擬機

  • 安排合適的機器尺寸
  • 尺寸較小的先占虛擬機,可用性較高。意思是零碎的先占虛擬機容易取得

但當然也不能都開太小的機器,這會嚴重影響應用的分配。至於具體需要開多大,可以根據預計在機器上運行的應用,做綜合考量,例如有以下影用需要執行:

  • app A: 1 cpu 5 replica
  • app B: 3 cpu 5 replica
  • app C: 5 cpu 5 replica

總共至少 45 cpu ,預期機器負載8 成的話,需要總共 45 / 0.8 = 56 cpu。也許可以考慮

  • 8 cpu * 7 先占虛擬機
  • 4 cpu * 14

也舉幾個極端不可行的例子

  • 56 cpu * 1
    • 這樣的虛擬機回收時的影響範圍 (blast radius) 就是 100% 服務
  • 1 cpu * 56
    • 機器太瑣碎,可能超出 Qouta (節點數量,IP 數量...)
    • 應用會更分散,節點間的內部網路流量會增加
    • 前幾篇提到的 reserved resource 比例高,會影響應用的部署

如果希望更保險,可以再補上隨選虛擬機混合搭配,例如

  • 8 cpu * 7
    • 5 先占虛擬機 2 隨選虛擬機
  • 4 cpu * 14
    • 10 先占虛擬機 4 隨選虛擬機

虛擬機區域

虛擬機的回收觸發,也是會依據服務的區域 (zone) 回收。意思是節點回收不會同時觸發 asia-east1 中所有 zone 的節點回收,一般來說時間是錯開的 (不過GCP 也不保證這點 XD)。為了維持 GKE 的可用性,我們都會開多個 node-pool 在多個區域下。

總之避免把機器都放在同個區域中。

自行控制的虛擬機汰換

簡單來說我們在 24 hr 期限之前,先分批自盡 XD,打散個各個虛擬機的 24 小時限制。

使用這個有趣的工具 estafette-gke-preemptible-killer,自動汰換先占虛擬機,讓整個繼起虛擬機都分散在 24 小時間。

estafette-gke-preemptible-killer ,使用上簡單,大家自己看著辦 XD。如果大家有興趣,留言的人多的話,我再另外開一篇細講。

小結

為了使用先占虛擬機,我們要多做以下幾件事

  • 為應用設計可容錯分散式架構,例如應用可以同時執行一樣的 API server 3 個 replica
  • 分散 Pod 到合適的機器上,例如設置 PodAntiAffinity
  • 設定合適的虛擬機大小,合適的分散應用
  • 使用 estafette-gke-preemptible-killer,自動汰換先占虛擬機
  • 不依賴應用的 Graceful-shutdown 流程

有寫過鐵人賽的都知道 30 篇真的很漫長,一篇文章幾千字,都要花好幾個小時。我去年後半,真的都會看讀者的留言跟按讚,取暖一波,才有動力繼續寫。留言的人多就會多寫,留言的人少就會少寫,各位覺得文章還看得下去,請務必來我粉專按讚留個言,不管是推推、鞭鞭、或是有想看的文章來許願,都十分歡迎。有你們的支持,我才有動力繼續寫。

請大家務必以實際行動支持好文章,不要讓劣幣驅逐良幣。不然 iThome 上面之後只剩洗觀看數的熱門文章了 XD

當然,沒人留言我就會當作自己才是垃圾文 (自知之明XD),就會收一收回家嚕貓睡覺,掰掰~

我的粉專,等你來留言


上一篇
Day 15 - 先占節點 Preemptible Instance 實戰分享,先占虛擬機如何殺死你的 Pod,如何處置上篇
下一篇
Day 17 - 從零開始導入Terraform,Infrastructure as Code 架構即程式,公司完整導入流程
系列文
Kubernetes X DevOps X 從零開始導入工具 X 需求分析*從底層開始研究到懷疑人生的體悟*30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言